The invention relates in general to local area networks and in particular to local area networks incorporating Universal Serial Bus (USB) capabilities.
The computer industry has recently formulated a new serial bus standard for interfacing peripherals and devices to computers. The new serial bus standard is known as a Universal Serial Bus (USB). The USB is a four wire bus which supports isochronous and asynchronous communications, multiple sub-channels of varied payload sizes for fan out of up to 127 USB devices (including low power USB devices), integrated powering for low power USB devices, simple connectors and hot plug and play for easy addition and removal of USB devices by a user. The Universal Serial Bus has its own protocol, the USB protocol, which supports two transmission speeds, full speed (12 Mbs) for full speed USB devices and low speed (1.5 Mbs) for low speed USB devices.
FIG. 1 shows a computer network comprising a host computer, a Universal Serial Bus, and a plurality of USB devices. In particular, a USB interface (typically called a root hub interface or root hub device) from the host computer offers at least one USB port but typically offers a plurality of USB ports (e.g. 2 which share a specified bandwidth of the USB interface) to which the USB devices may connect over cables not exceeding 5 meters. Additional USB devices can be supported in the bandwidth through the use of a special type of USB device, a USB hub device. Up to five USB hub devices may be daisy chained. That is, a first USB hub device may be connected, to one of the USB ports of the USB interface with a cable not exceeding 5 meters. The first USB hub device typically provides a number of additional USB ports (e.g. 4) to which additional USB devices may be connected over cables not exceeding 5 meters. A second USB hub device may be connected to one of the USB ports of the first USB hub device by a cable not exceeding 5 meters. Up to 5 USB hub devices may be daisy chained in this way. The length of each cable segment cannot exceed 5 meters (i.e. the reach limitation of each cable segment is 5 meters). Only USB devices, other than a USB hub device, may be connected to the fifth USB hub device. Consequently, the furthest a USB device can be from the host computer is 30 meters (six 5 m cables). i.e. the total reach limitation is 30 meters according to the USB protocol. There are a variety of USB devices that can be connected to a Universal Serial Bus ranging from: printers, scanners, video cameras, keyboards, monitors, telephones, label printers, bar code readers, modems, disk drives, etc. Many of the new computers sold today, (such as personal computers (PC""s) and the new iMac*), have at least one USB port.
*Trade-mark 
Many of the USB devices which can be connected to the host computer via the Universal Serial Bus can also be advantageously used for applications running over a communications network (such as a local area network (LAN) or a wide area network (WAN)), to allow remote computers, servers or even telephone switches to exploit their functionality. Communication software and hardware within the host computer can mediate the connection between the communications network and the Universal Serial Bus, but this solution has drawbacks. The host computer used to mediate the connection between the communications network and the Universal Serial Bus can suffer from common reliability problems caused by the host computer being crashed, the host computer being infected by a virus, the host computer being powered off or even the host computer being removed (e.g. a notebook PC being used as the host computer). Furthermore, for USB devices placed in conference rooms, reception areas, hotel rooms, etc., deploying at least one host computer (such as a PC) in every such room is usually not practical nor cost efficient. Furthermore, many devices, such as a telephone, do not inherently need or use the functionality of the host computer beyond the network connectivity it provides. The invention disclosed herein will address these drawbacks.
Each USB hub device (including the root hub interface or root hub device) has a hub controller for controlling the USB ports (also called sub-tending ports). The hub controller can be accessed via data transfers on the Universal Serial Bus between the host computer and the USB hub device.
The host computer runs Operating System software (OS) that includes USB host software, client software and device drivers. The USB host software manages the Universal Serial Bus. The client software is typically one or more software programs for one or more applications such as word processing, communications, spreadsheets or software programs (including device drivers) designed to interact with external devices such as printers, scanners, modems, etc. The client software and the USB host software interact with each other. (Discussed in more detail later).
Once a USB device (including a hub device) is first connected to a USB port, the USB host software assigns a unique USB device address to the USB device. A given USB device typically has a plurality of sub-functions contained within it. The host computer interacts with each sub-function by exchanging data with a corresponding unique end point within the USB device. Each end point has a unique end point number.
Every USB device has at least one end point, end point 0 (sometimes called control end point 0), which is a control end point for the device (e.g. the hub controller for a hub device is addressed through end point 0). Through interaction with the control end point 0, the USB host software in the host computer can determine what other end points are available on the USB device for interactions with client software as well as configure these end points or reset the USB device. All the other end points (i.e. all the end points other than the control end point 0) are sometimes called functional end points. A functional end point can either receive data from the host computer or transmit data to the host computer but not typically both. Control end point 0 can both receive data from the host computer and transmit data to the host computer.
Each USB port uses four wires, two data wires for data transmission and reception and two wires for carriage of power (one 5 volt source power wire and one ground wire).
Each USB hub device detects the connection or disconnection of USB devices from the USB hub device by sensing the amount of current flowing through each USB port. As mentioned earlier, two general types of USB devices can be connected to a USB hub device, low speed USB devices which operate at the low speed (1.5 Mbs) and full speed USB devices which operate at the full speed (12 Mbs). These different USB devices cause different current draw characteristics when attached to a USB port in order that a full speed USB device can be distinguished from a low speed USB device. When a low speed USB device is connected to a USB port, the USB port is sometimes called a low speed port. Similarly, when a full speed USB device is connected to a USB port, the USB port is sometimes called a full speed port.
Every USB hub device manages the status of each of its USB ports. When a USB device is first connected to one of the USB ports of a USB hub device, the USB hub device changes the status of the USB port from a disconnected state to an attached state. In the attached state, regular bus communication does not flow through the USB port to the USB device. When a USB device is disconnected from one of the USB ports of a USB hub device, the USB hub device changes the status of the USB port to the disconnected state. The USB host software polls each hub device periodically and the USB hub device indicates whether the status has changed for any of its USB ports. Once the USB host software has received indication of a status change for one or more USB ports, the USB host software will issue commands to the hub controller of the USB hub device (via its control end point 0) to determine the nature of the status change and react accordingly for each changed USB port in turn. For instance, the USB host software will respond to a new USB device connected to a USB port by sending a reset command, directed to the USB port of the USB hub device connected to the newly attached USB device. The USB device sends the reset command via the USB port to the newly attached USB device. The USB device will respond by placing itself in a default state. In the default state, the USB device responds to a USB device address 0. After the reset command has been completed, the USB hub device changes the status of the USB port from the attached state to a default state. Once a USB port is in the default state, regular bus communications can flow through the USB port to the USB device using USB device address 0. Next, the USB host software will issue a command to the USB device (using the USB device address 0) to assign a new, unique USB device address to the USB device. Once assigned, the host can now enable another recently connected USB device at another USB port with the USB device address 0. Once a USB device has been given a device address, the USB device still requires a configuration command before it can be used. When a USB device has a device address but is not configured, the USB device and the respective USB port are in an addressed state. In the addressed state, only the control end point 0 of the USB device can be addressed by the USB host software. The USB host software typically issues commands to the control end point 0 of the USB device requesting a description of the USB device""s end points. (buffer sizes, direction and service rates), a description of the USB device""s manufacturer, model and serial number and even a description of the USB device (e.g. a brand X USB colour printer). These descriptions are made available to the client software by the USB host software. Once the client software needs to use a USB device, the configuration command is issued to the USB device by the USB host software, whereupon the USB device and the respective USB port will be placed in a configured state. A user typically interacts with the USB device through the mediation of client software. In the configured state, the device""s functional end points become operational in addition to its control end point. (The only exception relates to USB hub devices which cannot be accessed by client software. Only the USB host software can access hub devices. Consequently, the USB host software issues the configuration command to each USB hub device independently of the client software).
Closing communication with a USB device, other than a USB hub device, in the configured state can be initiated by the client software. Any such request from the client software is intercepted by the USB host software. The USB host software sends a de-configuration command to the USB device. Upon receipt, the USB device and the respective USB port are placed in the addressed state. If the USB device is physically disconnected from the USB hub device (including the root hub device), the USB hub device changes the status of the USB port to the disconnected state. As mentioned earlier, the USB host software polls each USB hub device periodically. During these periodic polls, the USB device will indicate to the USB host software that the USB device has been disconnected from the USB port.
Information is carried on the Universal Serial Bus in packets (xe2x80x9cUSB packetsxe2x80x9d). Packets sent at the low speed are called low speed transmissions. Similarly, packets sent at the full speed are called full speed transmissions. Each USB packet transmitted on the Universal Serial Bus is delineated by sync fields (for clock recovery) at the start of each USB packet, followed by the USB packet, and ending with a special end of USB packet signalling on the Bus. Referring to FIGS. 2A, 2B, 2C, 2D and 2E, the USB protocol supports five different main types of USB packets: a token packet, a start of frame packet, a data packet, a handshake packet and a special low speed preamble packet. At the beginning of each USB packet is a packet identifier or PID. According to the USB protocol, there are ten different types of PID""s.
USB packets are sent within a plurality of transmission frames. Each frame is one millisecond long. Referring to FIG. 2B, start of frame packets are issued from the USB host software according to a precise one millisecond schedule. Each start of frame packet consists of a start of frame PID, a frame number and a CRC for error checking.
Data is carried on the Universal Serial Bus through the use of USB transactions. A USB transaction involves transmission of up to three USB packets for full speed transmissions and four packets for low speed transmissions. The USB host software formats the data destined to the USB devices into USB packets according to the USB protocol. (Described in more detail below). Similarly, each USB device formats data destined to the host computer into USB packets according to the USB protocol. (Described in more detail below).
Data is either transferred (xe2x80x9ca data transferxe2x80x9d) from the host computer to a USB device (an xe2x80x9cOut transactionxe2x80x9d or an xe2x80x9cUSB Control Setup transactionxe2x80x9d) or from a USB device to the host computer (an xe2x80x9cIn transactionxe2x80x9d). There are three types of token packets: an In token packet for In transactions, an Out token packet for Out transactions and a Setup-token packet for USB Control Setup transactions. Referring in particular to FIG. 2A, the PID of the token packet identifies the type of the token packet. (i.e. there are three different PID""s for token packets: one for Out token packets, one for In token packets and one for Setup token packets). Each token packet also contains a field for the USB device address and a field for the end point number of the USB device to which the USB transaction is addressed. Finally, each token packet contains a field for a CRC check used for error checking. Information in the token packet (i.e. the type of token packet, the USB device address, the end point number and the CRC) is sometimes called a token.
Each USB transaction typically begins when the USB host software in the host computer, on a scheduled basis, sends a token packet. The USB device that is addressed selects itself by decoding the USB device address contained in the token packet.
Following the token packet, a data packet is typically sent either from the USB host software or the USB device depending on the type of the token packet. Referring to FIG. 2C, each data packet consists of a PID, data and a CRC for error checking. There are two PID""s used for data packets: a Data 0 PID and a Data 1 PID. These two PID""s provide for alternating 0,1 labelling of data packets for sequence error checking. (Isochronous transactions are not checked for sequence errors since all data packets use data 0 PID). A proper sequence of data packets occurs when no two consecutive data packets to or from the same end point number of the same USB device have the same PID. i.e. The first data packet sent to or from a USB device will use the data 0 PID, the second data packet sent to or from the same USB device will use the data 1 PID, the third data packet sent to or from same USB device will use data 0 PID, etc. If a USB device or the USB host software receives two consecutive data packets addressed to the same end point number with the same PID, a sequence error has occurred.
The data can be up to 1024 bytes for isochronous communications and up to 64 bytes for asynchronous communications. A data payload size is the number of bytes in the data. Specific data payload sizes are associated with each endpoint.
Referring to FIG. 2D, for asynchronous communications, the USB host software or the USB device that received the data packet responds with a handshake packet. There are three types of handshake packets: an acknowledgement handshake packet (or ACK handshake packet), a negative acknowledgment handshake packet (or NAK handshake packet) or a Stall handshake packet. The type of handshake packet is indicated by the PID in the handshake packet. (i.e. there are three different PID""s for handshake packets: one for acknowledgement handshake packets, one for NAK handshake packets and one for Stall handshake packets).
As mentioned earlier, there are low speed USB devices and full speed USB devices which can be connected to the Universal Serial Bus. The hub controller in each USB hub device disables transmission on the low speed USB ports during full speed transmissions on the Universal Serial Bus and vice-versa for low speed transmissions on the Universal Serial Bus. Low speed transmissions are preceded by a special low speed preamble packet which informs the USB hub devices that a low speed transmission follows; upon receipt of this packet, the USB hub devices disable the full speed USB ports and enable the low speed USB ports until the USB hub devices detect the end of the low speed transmission upon which the USB hub devices disable the low speed USB ports and enable the full speed USB ports. Referring to FIG. 2E, the special low speed preamble packet consists of a special low speed preamble PID which identifies the packet as a low speed preamble packet.
Referring to FIGS. 3, 4, 5 and 6, there are four types of USB transactions: USB isochronous transactions, USB bulk or control data transactions, USB interrupt transactions and USB control setup transactions. Each functional endpoint of a USB device is associated with one of the above types of transactions. These figures illustrate the three different types of token packets: the In token packet (for In transactions), the Out token packet (for Out transactions), and the Setup token packet (for USB Control Setup transactions). It should be noted that interrupt and USB control setup transactions are just special instances of USB bulk or control data transactions. USB isochronous transactions are used for isochronous communications. USB bulk or control transactions, USB interrupt transactions and USB control Setup transactions (collectively called xe2x80x9cUSB asynchronous transactionsxe2x80x9d) are used for asynchronous communications.
Data is transmitted from a transmit data buffer in the USB device (corresponding to an end point number) to a receive data buffer in the USB host software. Similarly, data is transmitted from a transmit data buffer in the USB host software to a receive data buffer (corresponding to an end point number) in the USB device. The USB host software schedules the transmission of the data between the transmit data buffers and the receive data buffers in the USB devices and the USB host software.
For each frame, the USB host software typically schedules the USB isochronous transactions first followed by the USB asynchronous transactions. In other words, the scheduling for the USB isochronous transactions is typically fixed. Other schedules are possible.
As shown in FIG. 3, USB isochronous transactions attempt to guarantee a data rate. When the USB host software wishes to send data to a USB device (an Out isochronous transaction), it issues an Out token packet and transmits a data packet within a USB time limit as prescribed by the USB protocol. Similarly, when the USB host software wishes to receive data from a USB device (an In isochronous transaction) it issues an In token packet to the USB device and waits for a data packet to be transmitted from the USB device to the host computer. If the In token packet was never received correctly by the USB device (i.e. a token error), the USB device never sends a data packet. The USB host software does not typically retry USB isochronous transactions containing errors. As shown in FIG. 3, with isochronous transactions, handshake packets are not involved.
In contrast, USB bulk or control data transactions are not sent at a guaranteed data rate but attempt to guarantee delivery by the use of handshake packets. A USB bulk transaction is used to transfer data such as data in a file transfer. A USB control transaction is used to send data to control end point zero of a USB device. Referring to FIG. 4, when the USB host software wishes to send data to a USB device (an Out bulk/control transaction), it issues an Out token packet and it sends a data packet within the USB time limit as prescribed by the USB protocol. If the data packet was received properly by the USB device, the USB device issues the acknowledgement handshake packet (an ACK handshake packet) within the strict USB time limit after receiving the data packet. If the USB device is not ready to accept data on the bus, the USB device issues the NAK handshake packet. It should be noted that the NAK handshake packet does not represent an error. If the USB device is in a condition that prevents normal operation of the USB device, the USB device issues the Stall handshake packet. If the USB host software does not receive the ACK handshake packet, the NAK handshake packet or the Stall handshake packet within the USB time limit after sending the data packet, the USB host software assumes that either a token or a data error has occurred. The USB host software will typically retry the USB transaction (as discussed in more detail below).
Similarly, if the USB host software wishes to receive data from a USB device (an In bulk/control transaction), it issues an In token packet. If the USB device receives the In token packet error-free and the USB device has data, the USB device sends a data packet to the computer within the USB time limit after receiving the In token packet. Upon error free receipt of the data packet, the USB host software issues the ACK handshake packet to the USB device. If the USB device does not receive the ACK handshake packet error free within the USB time limit after sending the data packet, it assumes a data error has occurred. The next time the host software issues an In token packet to the same end point number of the same USB device, the USB device will re-send the same data packet previously sent.
The USB host software will recognize that the USB device has re-sent the same data packet by examining the data PID. If the USB host software receives two consecutive packets with the same data PID (i.e. both data packets have a Data 0 PID or a Data 1 PID), a sequence error has occurred. To fix the sequence error, the host software discards the duplicate data, sends an ACK handshake packet to the USB device and sends another In token packet to the USB device. If the USB host software never received the data packet error free, then the USB host software would have never sent an ACK handshake packet. The USB host software will resend the In token packet to the USB device. Upon error-free reception of the In token packet, the USB device re-sends the data packet. Since the USB host software never received the data packet error-free previously, the error free reception of the data packet resumes the proper sequence of data packets.
After receiving the In token packet, if the USB device is not ready to send data to the computer, the USB device issues the NAK handshake packet. After receiving the In token, if the USB device is a condition which prevents normal operation of the USB device, the USB device issues the Stall handshake packet to the host computer. If the USB host software does not receive the data packet, the NAK handshake packet or the stall handshake packet within the USB time limit after issuing the In token, the USB host software assumes that a token error has occurred. The USB host software then retries the transaction at a future time (as discussed in more detail below).
A USB Interrupt transaction is used to service a USB device that does not need a very high throughput (e.g. a keyboard or a mouse). Each USB Interrupt transaction attempts to guarantee delivery and uses a minimal service interval. Referring to FIG. 5, when the USB host software wishes to receive data from a USB device, such as a mouse, the USB host software issues an In token packet to the USB device. If the USB device has data to send, the USB device sends a data packet to the host computer within the USB time limit after receiving the In token packet. If the data packet is received error free by the USB host software, the USB host software issues the ACK handshake packet to the USB device within the USB time limit after receiving the data packet. If the device does not receive the ACK handshake packet, the USB device assumes that a data error has occurred. After the USB host software issues an In token packet, if the USB device is not ready to send data to the host computer, the USB device sends the NAK handshake packet to the host computer. After the USB host software issues an In token packet, if the USB device is in a condition which prevents normal operation of the USB device, the USB device issues the stall handshake packet to the computer. If the USB host software does not receive a data packet, the NAK handshake packet or the Stall handshake packet within the USB time limit after sending the In token packet, the USB host software assumes that a token error has occurred and retries the USB transaction at a future time (discussed in more detail below).
Referring to FIG. 6, a USB control setup transaction is used to initially configure a USB device. The USB host software sends a Setup token packet and sends a data packet to the USB device within the USB time limit after sending the Setup token packet. If the USB device receives the data packet error free, the USB device sends the ACK handshake packet to the computer within the USB time limit after receiving the data packet. If the USB host software does not receive the ACK handshake packet within the USB time limit after sending the data packet, it assumes that a token or data error has occurred and retries the transaction at a later time. (Discussed in more detail below). USB control setup transactions have highest priority for a USB device and as such should always be ready to accept the data packet. Consequently, a NAK handshake packet is not permitted.
Data errors are handled on the Universal Serial Bus in the following way. Isochronous transactions and asynchronous transactions are checked for errors using the CRC in each token packet and using the CRC in each data packet. Any asynchronous transaction which has errors are automatically retried by the USB host software for a maximum of three times. If an error still persists after three tries, the USB host software notifies the client software of the error. Isochronous transactions which have errors are not specified to be retried by the USB host software. The USB protocol also provides for alternating 0,1 labelling of the data packets along with corresponding ACK token packets to recover from possible corrupted handshake packets and to resume the proper sequence of data packets.
A USB port on a USB device is sometimes called a device USB port. Similarly, a USB port on a computer is sometimes called a host USB port. More generally, a host USB port is a USB port to which to USB device may be connected. A host USB device is a device, such as a host computer, with at least one host USB port controlled by USB host software.
Like many conventional protocols, the USB protocol is a layered protocol comprising a number of layers. One of the layers is a physical layer which defines the electrical specifications of the Universal Serial Bus. Another layer is a data link layer which defines the types of transactions permissible on the Universal Serial Bus (i.e. the formats of the USB transactions). USB specification 1.0 authored by Compaq, DEC, IBM, Intel, Microsoft, NEC and Nortel and published on Jan. 15, 1996 defines the specifications and functionality of the Universal Serial Bus. The USB specification 1.0 is incorporated by reference herein.
In particular, the USB specification 1.0 defines the functionality required in the host software in order for the computer to interact with USB devices attached to the Universal Serial Bus. In general, the functionality of any host computer application using the Universal Serial Bus can be divided into four basic components:
(1) The functionality of the client software and device drivers,
(2) The functionality of the USB host software,
(3) The functionality of the physical and data link layers, and;
(4) The functionality of the USB devices.
There are time sensitive aspects of the USB protocol. As specified in the USB Specification 1.0, and as mentioned earlier, there is a USB time limit (or maximum delay) between an Out token packet and a data packet, the same USB time limit (or maximum delay) between the sending of the data packet and the reception of the ACK handshake packet, the NAK handshake packet or the stall handshake packet and the same USB time limit (or maximum delay) between the transmission of the In token packet and the reception of the data packet, NAK packet or Stall packet.
The above three cases are part of the time sensitive aspects of the USB protocol. The USB time limit (or maximum delay) is 7.5 bit times (0.625 microseconds for 12 Mbs transmissions and 5.0 microseconds for 1.5 Mbs transmissions).
However, no time limits are specified between USB transactions. Due to the USB time limits (and other processing limits in the USB devices), USB devices will not operate more than 30 meters from a host computer (by using daisy chaining of hub devices discussed earlier). Consequently, the Universal Serial Bus does not lend itself to local area network (LAN) applications which typically require that a plurality of devices be 100 meters or more from a server. (A server is a computer which manages the local area network).
An object of one aspect of the present invention is to provide a local area network incorporating Universal Serial Bus capabilities.
Another object of the present invention is to overcome the reach limitations of the USB protocol.
Another object of the present invention is to allow a USB device to interface to a LAN network and interact with remote computers, servers or telephone switches without the mediation of a local personal computer (PC).
In accordance with one aspect of the present invention, there is provided a computer network comprising a LAN hub, at least one network device connected to the LAN hub, at least one outer hub device connected to the LAN hub and at least one USB device or at least one LAN computer connected to the outer hub device via a respective USB link. The USB device or the LAN computer communicates with the outer hub device using the USB protocol. The outer hub device communicates with the LAN hub using the LAN protocol. The network device communicates with the LAN hub using the LAN protocol or a network protocol. In a preferred embodiment, for asynchronous communications, the outer hub device examines USB packets from the USB device or the LAN computer, generates handshake packets in response to the USB packets according to the USB protocol and ensures that the handshake packets are generated within a USB time limit prescribed by the USB protocol after receiving the USB packets. The outer hub device buffers data received from the LAN hub to be sent to the USB device in a data packet and ensures that the data packet follows an Out token packet within the USB time limit prescribed by the USB protocol. Furthermore, the outer hub device buffers data received from the LAN hub to be sent to the LAN computer in a data packet and ensures that the data packet is sent to the LAN computer within the USB time limit prescribed by the USB protocol after receiving an In token packet from the LAN computer.
In accordance with another aspect of the present invention, there is provided a computer network comprising a LAN hub, at least one outer hub device connected to the LAN hub, at least one other outer hub device connected to the LAN hub via a respective LAN link, at least one USB device or at least one LAN computer connected to the outer hub device via a respective USB link and at least one other LAN computer connected to the other outer hub device via a respective USB link. The USB device and the LAN computer communicates with the outer hub device using the USB protocol. The other LAN computer communicates with the other outer hub device using the USB protocol. The outer hub device and the other outer hub device communicates with the LAN hub using a LAN protocol. In a preferred embodiment, for asynchronous communications, the outer hub device examines USB packets from the USB device or the LAN computer, generates handshake packets in response to the USB packets according the USB protocol and ensures that the handshake packets are generated within a USB time limit prescribed by the USB protocol after receiving the USB packets. In addition, the outer hub device buffers data received from the LAN hub to be sent to the USB device in a data packet and ensures that the data packet follows an Out token packet within the USB time limit prescribed time limit prescribed by the USB protocol. Furthermore, the outer hub device buffers data received from the LAN hub to be sent to the LAN computer in a data packet and ensures that the data packet is sent to the LAN computer within the USB time limit prescribed by the USB protocol after receiving an In token packet from the LAN computer. For asynchronous communications, the other outer hub device examines USB packets from the other LAN computer, generates handshake packets in response to the USB packets according to the USB protocol and ensures that the handshake packets are generated within the USB time limit prescribed by the USB protocol after receiving the USB packets. In addition, the other outer hub device buffers data received from the LAN hub to be sent to the other LAN computer in a data packet and ensures that the data packet is sent to the other LAN computer within the USB time limit prescribed by the USB protocol after receiving an In token packet from the other LAN computer.
In accordance with another aspect of the present invention, there is provided an end hub for use in a computer network in which the end hub communicates with at least one USB device using the USB protocol and in which the end hub communicates with a LAN hub using a LAN protocol. The end hub comprises LAN hub communication means for communicating with the LAN hub via a multi point access LAN link, USB device communication means for communicating with the USB device and control logic means connected to the LAN hub communication means and to the USB device communication means. In a preferred embodiment, for asynchronous communications, the control logic means examines USB packets from the USB device, generates handshake packets in response to the USB packets according to the USB protocol and ensures that the handshake packets are generated within a USB time limit prescribed by the USB protocol after receiving the USB packets. In addition the control logic means buffers data received from the LAN hub to be sent to the USB device in a data packet and ensures that the data packet follows an Out token packet within the USB time limit prescribed by the USB protocol.
In accordance with the another aspect of the present invention, there is provided an attachment unit for use in a computer network in which the attachment unit communicates with at least one LAN computer using the USB protocol and in which the attachment unit communicates with a LAN hub using a LAN protocol. The attachment unit comprises LAN hub communication means for communicating with the LAN hub via a multi point access LAN link, USB computer communication means for communicating with the LAN computer and control logic means connected to the LAN hub communication means and to the USB computer communication means. In a preferred embodiment, for asynchronous communications, the control logic means examines USB packets from the LAN computer, generates handshake packets in response to the USB packets according to the USB protocol and ensures that the handshake packets are generated within a USB time limit prescribed by the USB protocol after receiving the USB packets. In addition, the control logic means buffers data received from the LAN hub to be sent to the LAN computer in a data packet and ensures that the data packet is sent to the LAN computer within the USB time limit prescribed by the USB protocol after receiving an In token packet from the LAN computer.
In accordance with another aspect of the present invention, there is provided an enhanced attachment unit for use in a computer network in which the enhanced attachment unit communicates with at least one LAN computer using the USB protocol and in which the attachment unit communicates with a LAN hub using a LAN protocol. The attachment unit comprises LAN hub communication means for communicating with the LAN hub via a multi point access LAN link, USB computer communication means for communicating with the LAN computer and control logic means connected to the LAN hub communication means and to the USB computer communication means. The control logic means contains logic to virtually connect at least one USB device. In a preferred embodiment, for asynchronous communications, the control logic means examines USB packets from the LAN computer, generates handshake packets in response to the USB packets according to the USB protocol and ensures that the handshake packets are generated within a USB time limit prescribed by the USB protocol after receiving the USB packets. In addition, the control logic means buffers data received from the LAN hub to be sent to the LAN computer in a data packet and ensures that the data packet is sent to the LAN computer within the USB time limit prescribed by the USB protocol after receiving an In token packet from the LAN computer.
In accordance with another aspect of the present invention, there is provided a composite end hub for use in a computer network in which the composite end hub communicates with a LAN computer and with at least one USB device using USB protocol and in which the attachment unit communicates with a LAN hub using a LAN protocol. The composite end hub comprises LAN hub communication means for communicating with the LAN hub via a multi point access LAN link, USB device communication means for communicating with the at least one USB device, USB computer communication means for communicating with the LAN computer and control logic means connected to the LAN hub communication means, to the USB device communication means and to the USB computer communication means. In a preferred embodiment, for asynchronous communications, the control logic means examines USB packets from the USB device or the LAN computer, generates handshake packets in response to the USB packets according to the USB protocol and ensures that the handshake packets are generated within a USB time limit prescribed by the USB protocol after receiving the USB packets. In addition, the control logic means buffers data received from the LAN hub to be sent to the USB device in a data packet and ensures that the data packet follows an Out token packet within the USB time limit prescribed by the USB protocol. Furthermore, the control logic means buffers data received from the LAN hub to be sent to the LAN computer in a data packet and ensures that the data packet is sent to the LAN computer within the USB time limit prescribed by the USB protocol after receiving an In token packet.
In accordance with another aspect of the present invention, there is provided a method of establishing point-to-point communication between a LAN hub and an outer hub device over a multi point access LAN link to transmit LAN packets to and from the outer hub device according to a LAN protocol, the LAN hub being connected to at least one network device and the outer hub device being connected to at least one USB device or at least one LAN computer in a communication network where multiple outer hub devices are connected to the LAN hub via the multi point access LAN link, the method comprising marshalling the outer hub device via the multi point access LAN link, assigning a virtual line number (VLN) to the outer hub device marshalled via the multi point access LAN link and labelling each LAN packet to be transmitted to and from the outer hub device with the VLN assigned for point-to-point communication with the LAN hub via the multi point access LAN link.